Device, system and process for inmate release, holds, capacity management, bed space bid auction and data sharing

ABSTRACT

An inmate facility management system with a shared storage device and a processor configured to receive data and search requests from multiple disparate facility systems. The processor has an interface to translate data from the multiple disparate facility systems and store the data in the shared storage device. The processor executes booking requests, warrant requests and release requests using the shared storage device.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of and priority to U.S. ProvisionalPatent Application No. 62/332,774 filed May 6, 2016 the contents ofwhich is hereby incorporated by reference.

FIELD

The present disclosure generally relates to the field of correctionfacility management systems.

INTRODUCTION

An offender remanded for custody will be booked or assigned to acorrection facility, jail, detention centre, prison, penitentiary,remand centre, and the like. The offender may have been previouslyincarcerated at another facility. A facility system might not be able toaccess data about the same offender from the other facility system.There might be technical barriers due to incompatible data formats,different standards across different facilities, and a lack of physicalconnection between the data storage devices, for example. The segregatedfacility systems create data, processing and storage inefficiencies.

SUMMARY

In accordance with one aspect, the disclosure relates to data sharingacross disparate jail facility systems to generate a shared data storagesolution referred to as a virtual jacket system. The virtual jacketsystem synchronizes different data collections for multiple jailfacility systems. The virtual jacket system provides data sharing,capacity management, and release and hold control of inmates. Thevirtual jacket system has capacity bid-auction feature for managingavailable rooms and beds.

In accordance with another aspect, there is provided an inmate facilitymanagement system with a shared storage device and a processorconfigured to receive data and search requests from multiple disparatefacility systems, the processor having an interface to translate datafrom the multiple disparate facility systems and store the data in theshared storage device.

In accordance with another aspect, there is provided an inmate facilitymanagement system configured to receive a booking request, execute alocal and extended search using the booking request and a link between alocal inmate record and a shared inmate record, populate a bookingrecord using the results of the local and extended search, and updatethe local inmate record and the shared inmate record to indicate thebooking request.

In accordance with another aspect, there is provided an inmate facilitymanagement system configured to receive a warrant request, execute alocal and extended search using the warrant request and a link between alocal inmate record and a shared inmate record, generate a hold requestbased on the results of the local and extended search, and update thelocal inmate record and the shared inmate record to indicate the holdrequest.

In accordance with another aspect, there is provided an inmate facilitymanagement system configured to receive a release request, execute alocal and extended search using the release request and a link between alocal inmate record and a shared inmate record, populate a releaserecord using the results of the local and extended search, and updatethe local inmate record and the shared inmate record to indicate therelease request.

In accordance with another aspect, there is provided an inmate facilitymanagement system comprising: a shared storage device to store aplurality of inmate records and a plurality of facility records frommultiple disparate facility systems; an interface to receive a searchrequest for an open bed in a facility system for an inmate; a processorconfigured to: translate data from the multiple disparate facilitysystems to the plurality of inmate records and the plurality of facilityrecords; determine in real time a set of open beds for an aggregatedjail capacity using the plurality of inmate records and the plurality offacility records from the multiple disparate facility systems; updatethe interface to indicate the set of open beds for the aggregated jailcapacity; receive a booking request to book the open bed from the set ofopen beds; update an inmate record of the plurality of inmate recordscorresponding to the inmate and a facility record of the plurality offacility records corresponding to the facility system; populate abooking record for the open bed using the inmate record and the facilityrecord; and update the interface to display the booking request, theinmate record and the facility record.

In some embodiments, the processor is configured to process the bookingrequest by executing a local and extended search using a link between alocal inmate record and a shared inmate record, populate the bookingrecord using the results of the local and extended search, and updatethe local inmate record and the shared inmate record to indicate thebooking record.

In some embodiments, the processor is configured to receive a warrantrequest, execute a local and extended search using the warrant requestand a link between a local inmate record and a shared inmate record,generate a hold request based on the results of the local and extendedsearch, and update the local inmate record and the shared inmate recordto indicate the hold request.

In some embodiments, the processor is configured to receive a releaserequest, execute a local and extended search using the release requestand a link between a local inmate record and a shared inmate record,populate a release record using the results of the local and extendedsearch, and update the local inmate record and the shared inmate recordto indicate the release request.

In some embodiments, the inmate record has a plurality of fieldscomprising a global identifier and name data, the shared storage devicestoring an inmate phonetic key record linked to the inmate record by theglobal identifier, a phonetic key record linked to the inmate phonetickey by a phonetic key identifier, the inmate phonetic key recordcomprising a commonality rank, the phonetic key record comprisingencoding for transforming the name data into phonetic name data, theprocessor configured to process an inmate search request comprisingsearch name data for the inmate, generate phonetic search name data,determine that the phonetic search name data matches the phonetic namedata within the commonality rank, return the inmate record, and populatethe booking record using the inmate record.

In some embodiments, the shared storage device stores an alias recordhaving alias data, the alias record linked to the inmate record by theglobal identifier, the processor configured to generate phonetic aliasdata, determine that the phonetic search name data matches the phoneticalias data within the commonality rank, return the inmate record, andpopulate the booking record using the inmate record.

In some embodiments, the shared storage device stores a diminutiverecord having diminutive data and actual name data, the actual name dataof the diminutive record linked to the name data of the inmate record,the processor configured to generate phonetic diminutive data, determinethat the phonetic search name data matches the phonetic diminutive datawithin the commonality rank, return the inmate record, and populate thebooking record using the inmate record.

In some embodiments, the inmate record has a plurality of fieldscomprising a global identifier and name data, the shared storage devicestoring an alias record linked to the inmate record by the globalidentifier, the alias record having alias data, the processor configuredto process an inmate search request comprising search name data for theinmate, determine that the search name data matches the alias data,return the inmate record, and populate the booking record using theinmate record.

In some embodiments, the inmate record has a plurality of fieldscomprising a global identifier and name data, the shared storage devicestoring a diminutive record having diminutive data and actual name data,the diminutive record linked to the inmate record by the actual namedata of the diminutive record and the name data of the inmate record,the processor configured to process an inmate search request comprisingsearch name data for the inmate, determine that the search name datamatches the diminutive data, return the inmate record, and populate thebooking record using the inmate record.

In some embodiments, the processor is configured to synchronize the datastorage device storing the plurality of inmate records and the pluralityof facility records with updated data from the multiple disparatefacility systems.

In some embodiments, the processor is configured to synchronize the datastorage device by receiving an election to participate in data sharingfrom a first facility system, storing a new facility record for thefirst facility system, loading additional data from the first facilitysystem, translating the additional data into a common schema to updatethe plurality of inmate records, and creating a new queue record for ascheduler to continuously check the first facility system for furtherdata over a time period.

In some embodiments, the processor is configured to synchronize the datastorage device using an application programming interface between aclient interface at a first facility system and a cloud interface at thedata storage device.

In some embodiments, the processor is configured to synchronize the datastorage device by assigning unique global identifiers that are used forrecords of the disparate facility systems and the data storage device.

In accordance with another aspect, there is provided a process for aninmate facility management system. The process involves: storing, on ashared storage device, a plurality of inmate records and a plurality offacility records from multiple disparate facility systems; receiving, ata processor, a search request for an open bed in a facility system foran inmate; translating data from the multiple disparate facility systemsto the plurality of inmate records and the plurality of facilityrecords; determining, at the processor in real time, a set of open bedsfor an aggregated jail capacity using the plurality of inmate recordsand the plurality of facility records from the multiple disparatefacility systems; updating an interface to indicate the set of open bedsfor the aggregated jail capacity; receiving a booking request to bookthe open bed from the set of open beds; updating an inmate record of theplurality of inmate records corresponding to the inmate and a facilityrecord of the plurality of facility records corresponding to thefacility system; populating a booking record for the open bed using theinmate record and the facility record; and updating the interface todisplay the booking request, the inmate record and the facility record.

In some embodiments, the process involves processing the booking requestby executing a local and extended search using a link between a localinmate record and a shared inmate record, populating the booking recordusing the results of the local and extended search, and updating thelocal inmate record and the shared inmate record to indicate the bookingrecord.

In some embodiments, the process involves receiving a warrant request,executing a local and extended search using the warrant request and alink between a local inmate record and a shared inmate record,generating a hold request based on the results of the local and extendedsearch, and updating the local inmate record and the shared inmaterecord to indicate the hold request.

In some embodiments, the process involves receiving a release request,executing a local and extended search using the release request and alink between a local inmate record and a shared inmate record,populating a release record using the results of the local and extendedsearch, and updating the local inmate record and the shared inmaterecord to indicate the release request.

In some embodiments, the process involves generating the inmate recordwith a global identifier and name data, storing an inmate phonetic keyrecord linked to the inmate record by the global identifier, a phonetickey record linked to the inmate phonetic key by a phonetic keyidentifier, the inmate phonetic key record comprising a commonalityrank, the phonetic key record comprising encoding for transforming thename data into phonetic name data, processing an inmate search requestcomprising search name data for the inmate, generating phonetic searchname data, determining that the phonetic search name data matches thephonetic name data within the commonality rank, returning the inmaterecord, and populating the booking record using the inmate record.

In some embodiments, the process involves storing an alias record havingalias data, the alias record linked to the inmate record by the globalidentifier, generating phonetic alias data, determine that the phoneticsearch name data matches the phonetic alias data within the commonalityrank, returning the inmate record, and populating the booking recordusing the inmate record.

In some embodiments, the process involves storing a diminutive recordhaving diminutive data and actual name data, the actual name data of thediminutive record linked to the name data of the inmate record,generating phonetic diminutive data, determining that the phoneticsearch name data matches the phonetic diminutive data within thecommonality rank, returning the inmate record, and populating thebooking record using the inmate record.

In some embodiments, the process involves generating the inmate recordwith a global identifier and name data, the shared storage devicestoring an alias record linked to the inmate record by the globalidentifier, the alias record having alias data, the processor configuredto process an inmate search request comprising search name data for theinmate, determine that the search name data matches the alias data,return the inmate record, and populate the booking record using theinmate record.

In some embodiments, the process involves generating the inmate recordwith a global identifier and name data, storing a diminutive recordhaving diminutive data and actual name data, the diminutive recordlinked to the inmate record by the actual name data of the diminutiverecord and the name data of the inmate record, processing an inmatesearch request comprising search name data for the inmate, determiningthat the search name data matches the diminutive data, return the inmaterecord, and populating the booking record using the inmate record.

In some embodiments, the process involves synchronizing the data storagedevice storing the plurality of inmate records and the plurality offacility records with updated data from the multiple disparate facilitysystems.

In some embodiments, the process involves synchronizing the data storagedevice by receiving an election to participate in data sharing from afirst facility system, storing a new facility record for the firstfacility system, loading additional data from the first facility system,translating the additional data into a common schema to update theplurality of inmate records, and creating a new queue record for ascheduler to continuously check the first facility system for furtherdata over a time period.

In some embodiments, the process involves synchronizing the data storagedevice using an application programming interface between a clientinterface at a first facility system and a cloud interface at the datastorage device.

In some embodiments, the process involves synchronizing the data storagedevice by assigning unique global identifiers that are used for recordsof the disparate facility systems and the data storage device.

In another aspect, there is provided an inmate facility managementdevice having an interface to access a shared storage device storing aplurality of inmate records and a plurality of facility records frommultiple disparate facility systems, and receive a search request for anopen bed in a facility system for an inmate; and a processor configuredto: translate data from the multiple disparate facility systems to theplurality of inmate records and the plurality of facility records;determine in real time a set of open beds for an aggregated jailcapacity using the plurality of inmate records and the plurality offacility records from the multiple disparate facility systems; updatethe interface to indicate the set of open beds for the aggregated jailcapacity; receive a booking request to book the open bed from the set ofopen beds; update an inmate record of the plurality of inmate recordscorresponding to the inmate and a facility record of the plurality offacility records corresponding to the facility system; populate abooking record for the open bed using the inmate record and the facilityrecord; and update the interface to display the booking request, theinmate record and the facility record.

In another aspect, there is provide an inmate facility management systemwith: a shared storage device to store a plurality of inmate recordsfrom multiple disparate facility systems, a plurality of inmate phonetickey records, a plurality of phonetic key records, wherein an inmaterecord has a global identifier and name data, wherein an inmate phonetickey record has the global identifier, a phonetic key identifier and acommonality rank, wherein a phonetic key record has the phonetic keyidentifier and encoding for transforming the name data into phoneticname data; an interface to receive a search request for an inmate in afacility system, the search request having search name data for theinmate; and a processor configured to: translate data from the multipledisparate facility systems to the plurality of inmate records; processin real time the inmate search request, generate phonetic search namedata, determine that the phonetic search name data matches the phoneticname data within the commonality rank, return the inmate record from theplurality of inmate records of the multiple disparate facility systems;and update the interface to indicate the inmate record.

In some embodiments, the processor is further configured to: receive abooking request to book an open bed for the inmate; determine the openbed from a set of open beds for an aggregated jail capacity across thedisparate facility systems; populate a booking record for the open bedusing the inmate record, the booking record having the globalidentifier; and update the interface to display the booking record.

In some embodiments, the processor is configured to process the bookingrequest by executing a local and extended search using a link between alocal inmate record and a shared inmate record, populate a bookingrecord using the results of the local and extended search, and updatethe local inmate record and the shared inmate record to indicate thebooking request.

In some embodiments, the processor is configured to receive a warrantrequest, execute a local and extended search using the warrant requestand a link between a local inmate record and a shared inmate record,generate a hold request based on the results of the local and extendedsearch, and update the local inmate record and the shared inmate recordto indicate the hold request.

In some embodiments, the processor is configured to receive a releaserequest, execute a local and extended search using the release requestand a link between a local inmate record and a shared inmate record,populate a release record using the results of the local and extendedsearch, and update the local inmate record and the shared inmate recordto indicate the release request.

In some embodiments, the shared storage device stores an alias recordhaving alias data, the alias record linked to the inmate record by theglobal identifier, the processor configured to generate phonetic aliasdata, determine that the phonetic search name data matches the phoneticalias data within the commonality rank, return the inmate record, andpopulate the booking record using the inmate record.

In some embodiments, the shared storage device stores a diminutiverecord having diminutive data and actual name data, the diminutiverecord linked to the inmate record by the actual name data of thediminutive record and the name data of the inmate record, the processorconfigured to generate phonetic diminutive data, determine that thephonetic search name data matches the phonetic diminutive data withinthe commonality rank, return the inmate record, and populate the bookingrecord using the inmate record.

In some embodiments, the inmate record has a plurality of fieldscomprising a global identifier and name data, the shared storage devicestoring an alias record linked to the inmate record by the globalidentifier, the alias record having alias data, the processor configuredto process an inmate search request comprising search name data for theinmate, determine that the search name data matches the alias data,return the inmate record, and populate the booking record using theinmate record.

In some embodiments, the inmate record has a plurality of fieldscomprising a global identifier and name data, the shared storage devicestoring a diminutive record having diminutive data and actual name data,the diminutive record linked to the inmate record by the actual namedata of the diminutive record and the name data of the inmate record,the processor configured to process an inmate search request comprisingsearch name data for the inmate, determine that the search name datamatches the diminutive data, return the inmate record, and populate thebooking record using the inmate record.

In some embodiments, the processor is configured to synchronize the datastorage device storing the plurality of inmate records and the pluralityof facility records with updated data from the multiple disparatefacility systems.

In some embodiments, the processor is configured to synchronize the datastorage device by receiving an election to participate in data sharingfrom a first facility system, storing a new facility record for thefirst facility system, loading additional data from the first facilitysystem, translating the additional data into a common schema to updatethe plurality of inmate records, and creating a new queue record for ascheduler to continuously check the first facility system for furtherdata over a time period.

In some embodiments, the processor is configured to synchronize the datastorage device using an application programming interface between aclient interface at a first facility system and a cloud interface at thedata storage device.

In some embodiments, the processor is configured to synchronize the datastorage device by assigning unique global identifiers that are used forrecords of the disparate facility systems and the data storage device.

In another aspect, there is provided an inmate facility managementsystem with a shared storage device to store a plurality of inmaterecords from multiple disparate facility systems, an alias record havingalias data, and a diminutive record having diminutive data and actualname data, the inmate record having a global identifier and name data,the alias record linked to the inmate record by the global identifier,the diminutive record linked to the inmate record by the actual namedata of the diminutive record and the name data of the inmate record; aninterface to receive a search request for an inmate in a facilitysystem, the search request having search name data for the inmate; aprocessor configured to: translate data from the multiple disparatefacility systems to the plurality of inmate records; process in realtime the inmate search request, determine that the search name datamatches the alias data or the diminutive data, return the inmate recordfrom the plurality of inmate records of the multiple disparate facilitysystems; and update the interface to indicate the inmate record.

In some embodiments, the processor is further configured to: receive abooking request to book an open bed for the inmate; determine the openbed from a set of open beds for an aggregated jail capacity across thedisparate facility systems; populate a booking record for the open bedusing the inmate record, the booking record having the globalidentifier; and update the interface to display the booking record.

In some embodiments, the processor is configured to process the bookingrequest by executing a local and extended search using a link between alocal inmate record and a shared inmate record, populate a bookingrecord using the results of the local and extended search, and updatethe local inmate record and the shared inmate record to indicate thebooking request.

In some embodiments, the processor is configured to receive a warrantrequest, execute a local and extended search using the warrant requestand a link between a local inmate record and a shared inmate record,generate a hold request based on the results of the local and extendedsearch, and update the local inmate record and the shared inmate recordto indicate the hold request.

In some embodiments, the processor is configured to receive a releaserequest, execute a local and extended search using the release requestand a link between a local inmate record and a shared inmate record,populate a release record using the results of the local and extendedsearch, and update the local inmate record and the shared inmate recordto indicate the release request.

In some embodiments, the processor is configured to synchronize the datastorage device storing the plurality of inmate records and the pluralityof facility records with updated data from the multiple disparatefacility systems.

In some embodiments, the processor is configured to synchronize the datastorage device by receiving an election to participate in data sharingfrom a first facility system, storing a new facility record for thefirst facility system, loading additional data from the first facilitysystem, translating the additional data into a common schema to updatethe plurality of inmate records, and creating a new queue record for ascheduler to continuously check the first facility system for furtherdata over a time period.

In some embodiments, the processor is configured to synchronize the datastorage device using an application programming interface between aclient interface at a first facility system and a cloud interface at thedata storage device.

In some embodiments, the processor is configured to synchronize the datastorage device by assigning unique global identifiers that are used forrecords of the disparate facility systems and the data storage device.

In some embodiments, the storage device stores an inmate phonetic keyrecord having the global identifier, a phonetic key identifier and acommonality rank, the storage device stores a phonetic key record havingthe phonetic key identifier and encoding for transforming the name datainto phonetic name data, wherein the processor is configured to generatephonetic alias data, determine that the phonetic search name datamatches the phonetic alias data within the commonality rank, return theinmate record, and populate the booking record using the inmate record,a plurality of inmate phonetic key records, a plurality of phonetic keyrecords the processor configured to generate phonetic diminutive data,determine that the phonetic search name data matches the phoneticdiminutive data within the commonality rank, return the inmate record,and populate the booking record using the inmate record.

In some embodiments, the inmate facility management system is configuredto receive a booking request, execute a local and extended search usingthe booking request and a link between a local inmate record and ashared inmate record, populate a booking record using the results of thelocal and extended search, and update the local inmate record and theshared inmate record to indicate the booking request.

In some embodiments, the inmate facility management system is configuredto receive a warrant request, execute a local and extended search usingthe warrant request and a link between a local inmate record and ashared inmate record, generate a hold request based on the results ofthe local and extended search, and update the local inmate record andthe shared inmate record to indicate the hold request.

In some embodiments, the inmate facility management system is configuredto receive a release request, execute a local and extended search usingthe release request and a link between a local inmate record and ashared inmate record, populate a release record using the results of thelocal and extended search, and update the local inmate record and theshared inmate record to indicate the release request.

In various further aspects, the disclosure provides correspondingsystems and devices, and logic structures such as machine-executablecoded instruction sets for implementing such systems, devices, andmethods.

In this respect, before explaining at least one embodiment in detail, itis to be understood that the embodiments are not limited in applicationto the details of construction and to the arrangements of the componentsset forth in the following description or illustrated in the drawings.Also, it is to be understood that the phraseology and terminologyemployed herein are for the purpose of description and should not beregarded as limiting.

Many further features and combinations thereof concerning embodimentsdescribed herein will appear to those skilled in the art following areading of the instant disclosure.

DESCRIPTION OF THE FIGURES

In the figures, embodiments are illustrated by way of example. It is tobe expressly understood that the description and figures are only forthe purpose of illustration and as an aid to understanding.

Embodiments will now be described, by way of example only, withreference to the attached figures, wherein in the figures:

FIG. 1 is a view of a virtual jacket system according to someembodiments;

FIG. 2 is a view of another example virtual jacket system according tosome embodiments;

FIG. 3 is a view of a further example virtual jacket system according tosome embodiments;

FIG. 4 is a flowchart of a process for a booking according to someembodiments;

FIG. 5 is a flowchart of a process for receiving a warrant requestaccording to some embodiments;

FIG. 6 is a flowchart of a process for a release according to someembodiments;

FIG. 7 is a diagram of data structures and links for a search processaccording to some embodiments;

FIG. 8 is a diagram of a process for the virtual jacket system accordingto some embodiments;

FIG. 9 is a screenshot of an example graphical user interface with aninmate record according to some embodiments;

FIG. 10 is a screenshot of an example graphical user interface withsearch fields according to some embodiments;

FIG. 11 is a screenshot of an example graphical user interface withsearch fields according to some embodiments;

FIG. 12 is a screenshot of an example graphical user interface withsearch results according to some embodiments;

FIG. 13 is a screenshot of an example graphical user interface withalert records according to some embodiments;

FIG. 14 is a screenshot of an example graphical user interface with ahold feature according to some embodiments;

FIG. 15 is a screenshot of an example graphical user interface of inmateresults according to some embodiments;

FIG. 16 is a screenshot of an example graphical user interface withfacility data according to some embodiments;

FIG. 17 is a diagram of data structures and links for datasynchronization according to some embodiments; and

FIG. 18 is a diagram of a computing device according to someembodiments.

DETAILED DESCRIPTION

Embodiments of methods, systems, and apparatus are described throughreference to the drawings.

FIG. 1 shows a virtual jacket system 100 for shared data storage acrossdisparate jail facility systems 104. A facility system 104 may manageinmate workflows for a correction facility, jail detention centre,prisons, penitentiary, remand centre, and the like. The virtual jacketsystem 100 synchronizes and combines different data collections for themultiple facility systems 104. The virtual jacket system 100 providesdata sharing, capacity management, release and hold control of inmates,and other functionality. The virtual jacket system 100 has capacitybid-auction tools for managing available rooms and beds across the jailfacility systems 104. The virtual jacket system 100 has capacitybid-auction tools for managing available rooms and beds aggregatedacross multiple jail facility systems 104. Correction facility staff oradministrators operate user system 106 to access the virtual jacketsystem 100 and their local facility system 104 via network 102. Afacility system 104 can have a local data set and an expanded data setwith a connection to virtual jacket system 100. The expanded data setcan include data from other jail facility systems 104 to extend thelocal data set, for example.

When a prior booking record for an offender exists in the electronicvirtual jacket system 100 fewer man hours are required to safely andeffectively intake the offender and the resulting record is morecomplete and accurate. Labor intensive data entry can be reduced byefficiently transforming much of the data contained in the prior recordto the new record, or linking the prior record to the new record. Dataintegrity can be increased as multiple records may be merged by virtualjacket system 100 into a master record for the offender. The virtualjacket system 100 flags inaccurate, expired and inconsistent datapopulating the offender record using data verification rules and naturallanguage processing. The virtual jacket system 100 sends a notificationto user system 106 or facility system 104 for review and verification.

When each electronic facility system 104 operates in an isolated silo,corrections facility staff members do not gain this same level of accessand efficiency. If an offender has been previously booked then virtualjacket system 100 can access data from a neighboring jail or otherremote corrections facility system 104. In known systems, data entrybegins from a blank slate or is limited to local information of aprevious incarceration from the local facility system 104. Theadditional time for data entry often results in decreased attention tothe offender or an elevated number of staff required on duty. This mayalso lead to increased levels of human error in a high stressenvironment, and an increased ability for an offender to give false,incomplete or incorrect information.

Similar issues exist at the time an offender is released and back intothe public. The release process includes searching for active warrantsand hold requests (detainers) from other agencies or facility systems104. These steps require timeliness and availability of relevant data.Offenders might be released with outstanding warrants from otherneighboring local or state jurisdiction facilities. This requiresadditional effort and resources from law enforcement to verify releasestatus. Releasing an inmate that should be held for another crime orjurisdiction dramatically increases risks to the public. A potentiallyviolent offender might be released rather than be transferred and heldfor other crimes at another facility. Even when detainees are in placeand identified, the transfer process in this hold and transport scenariorequires extensive data entry as there is no ability to reuse the dataavailable from the originating facility. The data may also be inaccurateand incomplete. Past inmate history including suicide attempts, mentalhealth issues, aggression and previous incidents can significantlyimpact inmate, facility officer, and public safety and well-being.

Virtual jacket system 100 aggregates active offender information into acloud-based data warehouse. Virtual jacket system 100 providescorrectional facility systems 104 and user systems 106 with the abilityto share critical health and safety information and expeditelabour-intensive or error-prone processes. Virtual jacket system 100provides the ability to search other facility systems 104 activepopulation, as well as being able to leverage the historical data fromother jail systems to efficiently populate a new booking record. Thisgreatly reduces data entry time, error and risk that exist in currentapproaches. This approach reduces critical mistakes for both correctionsstaff and offenders' safety, working with accurate information regardingthe offender's most recent behavior and medical needs. This also affordsinstitutions more time to focus on supervision and rehabilitation of thegeneral population.

Law enforcement agencies also have increased ability to find activelywanted offenders already incarcerated at nearby facilities. Timecurrently spent on the phone and searching disparate or potentiallyout-of-date electronic warrant systems is mitigated by the ability tosearch a centralized and real-time data store. Electronic hold requestsnot only reduce the time spent to request the detainer, but alsofacilitate the booking process at the destination facility, as the dataoriginates from a common system.

The cloud-based data sharing and exchange improves facilities managementand jail capacity management across multiple participating facilitiesand/or jurisdictions. The search process can afford greater transparencyand manage jail or bed capacity at an aggregated level. The virtualjackets system 100 implements capacity management and enables automatedtransfer of inmates throughout a region or across multiple autonomousjail facilities. This may reduce overall costs as well as overcrowdingat select facilities. The technology provides visibility into availablecapacity across a collection of independent facilities and enable thatcapacity to be offered for inmate housing based on their special andspecific needs and characteristics. This aggregated capacity managementalso affords other external agencies (external systems 108) anopportunity to arbitrage and bid on excess capacity thru a reverseauction or bid process for available capacity to maximize overall thebed utilization and reduce overall costs without requiring additionalfacilities or increased bed capacity at any one agency or jurisdiction.

The virtual jacket system 100 can connect to external systems 108 totransmit reports based on inmate data and other data from facilitysystems 104 and receive data. For example, the external systems 108 maybe a government system and virtual jacket system 100 generates reportfor social security, health and so on by processing inmate data fromfacility systems 104. The virtual jacket system 100 implements dataintegration to aggregate data at different levels (e.g. state level,region level, organization level).

The virtual jacket system 100 provides a web based API for access to itsdata warehouse. The virtual jacket system 100 is a service for bookingand releasing inmates using facility system 104. The virtual jacketsystem 100 manages capacity for facility system 104 across a geographicarea. The virtual jacket system 100 identifies facilities and servicesfor special needs issues and provides a search interface for search andreport requests.

FIG. 2 is a view of another example virtual jacket system 100 accordingto some embodiments.

Virtual jacket system 100 has data storage 214 for storing aggregatedinmate records populated with data from facility systems 104 throughinterface 212. Virtual jacket system 100 has a processor executinginstructions in data storage 214 to configure a request unit 218 and asearch unit 216. The request unit 218 responds to data requests fromuser application 206, external system 108, and facility system 104.

The interface 212 has a translation layer to translate input data intothe data schema for the data storage 214. The data schema describes theentities involved in the inmate management workflow. The data storage214 may store the data flat. Multiple facility data sets are describedusing the same data schema when imported into the cloud warehouse usingthe API for virtual jacket system 100.

The virtual jacket system 100 generates and manages offender records andfacility records for multiple facility systems 104. The virtual jacketsystem 100 relates multiple offender instances across differentgeographical areas to aggregate the data. In some embodiments, thevirtual jacket uses a global identifier for offender instances to linksto booking instances. Search unit 216 searches historical data to detectif there is the same offender. Search unit 216 uses a search process toexecute queries and locate relevant offender instances. Request unit 218responds to search and data import requests received from facilitysystem 104 and user applications 106 to trigger search unit 216.

A facility system 104 runs a virtual jacket application to connect tothe virtual jacket system 100. The facility system 104 runs a localsearch based on a local inmate and operations data set stored in itslocal storage or external storage 212. The facility system 104 also runsa virtual jacket search based on an extended data set from virtualjacket system 100 and its data storage 214. The virtual jacket system100 enhances the search data set for facility system 104. The virtualjacket system 100 can transfer data to facility system 104 to updatesits local storage or external storage 212 in response to controlcommands. The virtual jacket system 100 links inmate records to localinmate records in local storage or external storage 212 using anidentifier or reference. The virtual jacket system 100 checks forinaccurate, incomplete or expired data in local inmate records. Thevirtual jacket system 100 sends a notification to facility system 104.The search may be based on inmate's name, including sounds, languagevariants, aliases, street names, nick names, and so on.

Searching for records in an electronic system based on a person's nameand pedigree information is a complex task. This becomes even morecomplex when dealing with data sets created, stored and updated bydifferent, independent systems. Identification can be facilitated withID cards, such as Driver Licenses or Passports. However, working withoffenders within a jail facility, ID cards are often not available, andcorrections facility staff must use verbally-stated and observable cuesinstead. This can create a varied data set that includes both informalnames and formal names, for example. A search process can expand thesearch terms to identify relevant records. The search unit 216 providesa search API and data modelling that helps solve this problem in severalways including the use of phonetic encoding an alias names, for example.The search unit 216 can implement string or character searches and canalso implement phonetic searching.

Phonetics pose an issue when correctly spelling a person's verballyspoken last name. There are many pre-existing algorithms developed bylinguists that attempt to address this issue using the phoneticattributes of worldwide languages and dialects. These algorithms canencode a last name into a phonetically invariant string. In theory,encoding two or more names with these algorithms, those that are spelleddifferently but are phonetically akin, should produce the same encoding.As a result, searching by the encoding instead of the misspelled nameproduces the match. Search processes may vary depending on itsbest-encoded languages and rate of false positives on phonetic matches.Generally, systems might produce only two distinct encodings (doublemetaphone). Hence, the encodings might typically be stored alongside alast name as additional column(s) in a traditional database system.

In some embodiments, the virtual jacket system 100 (and the search unit216) can apply a different storage and search approach. Each last namecan be encoded against each algorithm or encoding, resulting in avariant number of phonetic keys for each name. Instead of columnsaccompanying the pedigree data, these keys are instead stored in rows ofa child table related to the person's main data record. Each encoding ispaired with a numeric weighting factor that defines the commonality ofthe encoding. Each search begins by encoding the searched last name,resulting in one or more keys. The virtual jacket system 100 can use asearch that joins the person table with the phonetic keys table, andfilters through an OR'ed list of the searched name's encoded keys. Thematching results are then returned and sorted by the weighting factor,providing the most common matches at the top of the results list.Accordingly, the weighting factor can be generated based on thecommonality rank or similarity measurement.

A different problem can be exposed regarding first names, as people areknown by, or prefer to be called by, shortened (diminutive) versions oftheir given name. For example, Charles is often shortened to Charlie,Charley or Chuck. In some embodiments, the Virtual Jacket search unit216 implements an extensible database table that pairs together fullgiven names with their common variations. Similar to the last name, thesearch joins and filters the person table with the diminutives table,matching the searched first name to either the full or diminutiveversion of the searched first name. As a result, searching by any ofCharlie, Charley, Chuck or Charles will find a record stored in thesystem as any of these variations.

Beyond diminutive names, people are often given nicknames, or operateunder one or more aliases. Following a similar one-to-many relationaldatabase pattern, Virtual Jacket search unit 216 stores nicknames andaliases as rows in a child table related to the person data. Though thesearch screen provides a separated Alias search term, the user may notbe aware they were given an alias. To guard against this, unless theAlias search term is explicitly provided, Virtual Jacket System 100implements a search technique that assumes the searched name may also bean alias, and joins the alias table with the person table by the personrecord's identifier, ORing an additional search term to potentiallymatch the alias with the searched name.

Human factors, such as miss keyed data either at the time of data entryor at search, also play an important factor in accurately identifyingexisting information in an electronic system. The Virtual Jacket searchunit 216 may apply a weight factor to the encoded last names ascriteria. Damerau-Levenshtein Distance (Edit Distance) is a calculationthat can be applied to two strings resulting in a numeric value denotinghow identical they are. Four operations are allowed as the charactersfrom the two strings are compared: insertion (extra letter), deletion(missing letter), substitution (different letter), and transposition(out-of-order letters). These operations carry different weights basedon how common the mistake is amongst humans, and summed provide a totaldistance apart for the two strings. A post-processor on the VirtualJacket search unit 216 results calculates the edit distance of thesearched last name to each last name included in the search results.

Edit distance would ideally also be applied to first name and aliassearch terms. Since both search filter operations are currently appliedas exact matches instead of phonetic encodings, such as the last nameapproach, some potential matches may currently still be missed. Thoughdatabase engines have advanced to allow algorithms to be codedexternally and linked into the query engine, such as SQL Server CLRIntegration, calculation-intensive actions performed dynamically on arow-by-row basis across an entire result set severely degrades queryperformance. It is theoretically possible to load the necessary dataentirely into memory as a search tree. Instead of searching via thedatabase engine, the search would occur entirely in-memory, alsoapplying these calculations dynamically. The size of the search tree foran entire system's person data may require additional RAM to store it.However, once feasible, including first or diminutive names as well asaliases and nicknames that fall within a given tolerance would alsoassist finding miss keyed and misheard data.

Though the system provides individual fields for first, last and middlenames, when it comes to data from external sources, a system can neitherrely on such granularity of the name data, nor the consistency to whichthe data is formatted or ordered. Many systems often provide the name asa single string, some with comma-separated last-name first, some withspaced first-name first. To solve this, a name parsing process isincluded in the search API that is available to the external datatranslation layer. The parser accepts a full name in any format, andprovides last, first, middle, suffix (Jr., Sr., III, et al.) and title(Mr., Mrs., Dr., et al.) data elements that are separated as a resultfile. The parser also detects common multi-token patterns found in lastnames of many heritages, such as Von, Van Der, and Bin. Through this,names such as Ludwig Von Beethoven, Osama Bin Laden, and Johannes VanDer Waals are properly identified as only first and last names. Manyprocesses naïve of this pattern improperly identify Von, Bin and Van Der(or possibly only Van) as middle names. Double-word first names aredifficult to detect apart from a middle name, such as Billy Bob or MaryLou. An extensible dictionary of common double-word names similar to thediminutives approach, or providing the possibility of multiple resultsfrom the parser such that Billy Bob results in a first name only resultand first+middle name, would both assist solving this issue.

Referring to the weighting system applied by search unit 216 as apost-processor to the search results, the phonetic commonality and theedit distance can be calculated into the weight. As such, thehighest-ranking results are properly spelled and sound most similar.However, a match with the correct additional data point(s), such as anSSN, DOB, DOB and Birth Place, or Driver License Number, might be rankedmuch lower given poor spelling or a less-common phonetic variance. Thepost-processor would benefit further by giving rows penalty weights formissing or mismatched data in fields compared where search terms areavailable. Weighted this way, rows with matches in each data point wouldhit the top of the result set, instead of simply relying on the weightsof the name data.

Perhaps most importantly, images associated with the electronic recordsare provided so that the corrections facility staff may visuallyassociate the electronic record with the offender they are processing.Images, combined with other data points such as height, gender,ethnicity et al. provide final confirmation to the user that they haveidentified the correct pre-existing electronic record.

FIG. 3 is a view of an example virtual jacket application 300 accordingto some embodiments. Facility system 104 runs a virtual jacketapplication 300 as an interface to virtual jacket warehouse 306 vianetwork 102. The virtual jacket application 300 has a booking process302, incarceration process 304, and a release process 306.

FIG. 4 is a flowchart of a process 400 fora booking an inmate using afacility system 104 and virtual jacket system 100 according to someembodiments. FIG. 4 also shows a process 402 for transferring an inmate.

At 404, facility system 104 receives a booking request for an offender.In response, facility system 104 executes a local search for inmate dataor other data relating to the booking and facility, including availablecapacity. The booking request may include special needs of the offender.

At 406, facility system 104 determines whether an inmate record orinstance exists for the offender in the booking request. If so, at 408,facility system 104 expedites booking by populating the booking recordby copying historical data form the prior inmate record. The bookingrecord is linked to the inmate record. The historical data form theprior inmate record may be part of the facility system 104 local dataset for the extended data set for virtual jacket system 100.

If the inmate record or instance does not exist for the offender in thebooking request, at 410, facility system 104 determines whether thefacility system 104 is connected to virtual jacket system 100. If not,at 412, facility system 104 generates a new booking record using inputdata.

At 414, facility system 104 connects to virtual jacket system 100 toexecute an extended search for inmate data or other data relating to thebooking and other facilities, including available capacity atneighbouring facilities. The extended search uses data from virtualjacket warehouse 306 populated by multiple facilities. Even if a localinmate record or instance does exists, facility system 104 can connectto virtual jacket system 100 to execute an extended search to expeditethe booking process using data from virtual jacket warehouse 306.

FIG. 5 is a flowchart of a process 500 for receiving a warrant requestaccording to some embodiments.

At 502, facility system 104 receives a list of active warrants andincarcerations. The warrant request may identify one or more offendersthat may be at a facility. In response, facility system 104 executes alocal search for inmate data or other data relating to the warrantrequest.

At 504, virtual jacket system 100 determines that an offender record orinstance exists that identifies an offender for the warrant request. At506, virtual jacket system 100 requests a hold to pick up and transferthe offender. The virtual jacket system 100 generates an electronic holdrequest and transmits the hold request to the corresponding facilitysystem 104. The virtual jacket system 100 triggers an electronic remotehold that flags the offender for other facility system 104 searches toindicate that there is a warrant request for the offender.

If the inmate record or instance does not exist for the offender in thebooking request, at 508, facility system 104 determines whether thefacility system 104 is connected to virtual jacket system 100. If not,at 510, facility system 104 indicates that there is no hold ability forthe offender in the warrant request.

At 516, facility system 104 connects to virtual jacket system 100 toexecute an extended search for inmate data relating to the warrantrequest. The extended search uses data from virtual jacket warehouse 306populated by multiple facilities. Even if a local inmate record orinstance does exist, facility system 104 can connect to virtual jacketsystem 100 to execute an extended search inmate data relating to thewarrant request. If the virtual jacket system 100 locates inmate recordor instance relating to the warrant request, at 514, the virtual jacketsystem 100 triggers a remote hold for the inmate or an electronic holdflag for other facility search requests.

FIG. 6 is a flowchart of a process 600 fora release according to someembodiments.

At 602, facility system 104 executes a release request for holdsrelating to an inmate to be released. At 604, the facility system 104determines whether any electronic hold flags exist for the inmate fromthe release request. There may be existing holds or active warrants foran offender. If, at 606, the facility system 104 sends a notification toanother facility system 104 or agency to transfer the inmate.

At 608, facility system 104 connects to virtual jacket system 100 toexecute a release request for any holds relating to the release request.At 614, the virtual jacket system 100 executes an extended search forholds using data from virtual jacket warehouse 306 populated by multiplefacilities. Even if a local inmate record or instance exists, facilitysystem 104 can connect to virtual jacket system 100 to execute anextended search inmate data relating to the release request. If thevirtual jacket system 100 locates on inmate record or instance relatingto the release request, at 606, the facility system 104 sends anotification to another facility system 104 or agency to transfer theinmate. If there are no holds then the offender may be released at 610.

The virtual jacket warehouse 306 updates based on the booking process400, warrant process 500 and release process 600, results. For example,the virtual jacket system 100 triggers an update to the inmate record ofvirtual jacket warehouse 306 to indicate new booking, a hold flag and arelease event. The virtual jacket system 100 also updates the inmaterecord based on incidents at the facility. For example, an inmate may besick or get into a fight, and the like.

The virtual jacket system 100 and the facility systems 104 link inmaterecords and synchronize the extended data set for the inmate record withthe local data set for the inmate record. The virtual jacket system 100may check the virtual jacket warehouse 306 against the local data toflag inconsistent, inaccurate and expired data. Note to inventors:please provide further details on the synchronization process.

FIG. 7 is a diagram of data structures 700 and links for a searchprocess according to some embodiments. An offender or inmate record 702has different fields including a global identifier (JacketNumber),social security or insurance number, first name, middle name, last name,and so on. As noted, an inmate may be identified using differentvariations for their name, including nicknames, street names, aliases,and so on. An offender phonetic key record 706 links to the inmaterecord 702 by the JacketNumber, for example. The offender phonetic keyrecord 706 has different fields including offender phonetic keyidentifier, phonetic key identifier, commonality rank, and so on. Aphonetic key record 708 links to the offender phonetic key record 706 bythe phonetic key identifier, for example. The phonetic key record 708includes an encoding field. The encoding is used to generate phoneticdata by transforming name data. A diminutive record 710 has differentfields including a diminutive identifier that links to a name field ofthe offender or inmate record 702. An alias record 704 has differentfields including an alias identifier, the name and the JacketNumber.Example instructions 712 for a search.

The virtual jacket system 100 receives an inmate search request withsearch name data for the inmate. The inmate search request can be partof the booking process, hold process, alert process or warrant process,for example. In some embodiments, the virtual jacket system 100 uses aphonetic key record 708 to generate phonetic search name data usingencoding. The virtual jacket system 100 can compare the phonetic searchname data to phonetic name data to identify similar phonetic name datawithin the commonality rank. The commonality rank can be a similaritythreshold, for example. The virtual jacket system 100 can comparephonetic encoding for the search name data and phonetic encoding for thename data of the inmate record 702 to see if the encodings are similaror common. The commonality rank is used to define the acceptable rangeof similarity or commonality between the encodings. The commonality rankcan be of value or range of values for example. The commonality rank canbe defined as of a variance measurement for example. The phoneticencoder receives string or character data as input and generatesphonetic encoding as output. The phonetic encoding can be used byvirtual jacket system 100 for comparison to other phonetic encoding toidentify data that is phonetically similar. The phonetically similardata might not be similar when considering the string are characters ofthe data alone.

An offender phonetic key record 706 links phonetic name data to a globalidentifier. An inmate record 702 links the global identifier to namedata. The offender phonetic key record 706 has phonetic encodingrepresenting a name. The inmate record has string or character valuesrepresenting a name. Accordingly, the virtual jacket system 100 uses theglobal identifier to link the offender phonetic key record 706 with thephonetic encoding corresponding to name data to the inmate record 702with the string or character values for the name data. The virtualjacket system 100 can populate a booking record using the name data ofthe inmate record 702, for example. According, the virtual jacket system100 can determine that the phonetic search name data matches thephonetic name data within the commonality rank and return the inmaterecord in response. The phonetic search name data and the phonetic namedata can be different but still determined to sound phonetically similarenough if within the commonality rank, for example. The commonality rankcan define permitted ranges of phonetic variance. The inmate record 702can be linked to one or more facility records, for example. The virtualjacket system 100 uses phonetic encoding to identify relevant inmaterecords 702 in response to a search query that might not otherwise beidentified using a string or character comparison. For example, a firstname might use different strings or characters than a second name butmay sound phonetically similar. The virtual jacket system 100 can usethe offender phonetic key record 706 to match first name data and secondname data based on their phonetic similarity to generate search results.The virtual jacket system 100 can also use string or charactercomparisons to match the first name data and the second name data togenerate search results. Accordingly, the virtual jacket system 100 canidentify the first name data and the second name data based on theirphonetic similarity which may not otherwise be identified based onstring or character similarity.

The inmate record 702 has fields including a global identifier and namedata. The virtual jacket system 100 uses a shared storage device tostore inmate phonetic key records 706 and inmate records 702. Thevirtual jacket system 100 links the inmate phonetic key records 706 andinmate records 702 by the global identifier. The virtual jacket system100 can identify an inmate phonetic key record 706 based a phoneticsimilarity to name data received as part of a search or query. Thevirtual jacket system 100 links phonetic key records 708 to inmatephonetic key records 706 by a phonetic key identifier. The inmatephonetic key records 706 include a commonality rank to determiningsimilar phonetic names. A user may enter name incorrectly as a searchname but the correct inmate record 702 can be located by the virtualjacket system 100 using the inmate phonetic key records 706 and thephonetic key records 708. The phonetic key records 708 have encoding fortransforming the name data into phonetic name data. The virtual jacketsystem 100 can use the phonetic name data to identify an inmate phonetickey record 706.

An alias record 704 is linked to the inmate record 702 by the globalidentifier. The alias record has alias data. The system 100 can processan inmate search request with search name data for the inmate, determinethat the search name data matches the alias data, return the inmaterecord, and populate the booking record using the inmate record. Thevirtual jacket system 100 can use the alias data to generate searchresults and locate relevant inmate records 702. The virtual jacketsystem 100 can use the alias record 704 to match alias data to searchdata based on a similarity measure. The similarity measure can begenerated based on string or character similarities. The similaritymeasure can also be generated based on phonetic similarities. Thesimilarity measure can be referred to as a commonality rank which can beof value or range of values defining permitted variance between two ormore compared parameters, for example.

The system 100 can generate phonetic alias data. The system 100 candetermine that the phonetic search name data matches the phonetic aliasdata within the commonality rank, return the inmate record, and populatethe booking record using the inmate record. This creates a flexible toolfor system 100 to locate relevant inmate records and expands search datato include alias names. The virtual jacket system can use the aliasrecord 704 to match alias data to search data based on a similaritymeasure that can be generated using phonetic similarity between thealias data and the search name data. As noted, the alias record 704 withthe similar alias data can be used to identify the corresponding inmaterecord 702 based on the global identifier. Accordingly, the virtualjacket system 100 can identify an inmate record 702 based on similaritybetween alias data and search name data. The virtual jacket system 100can identify the inmate record 702 which may not otherwise be identifiedbased on a comparison between the stored name data in the inmate record702 and the search name. Accordingly, use of the alias data by virtualjacket system 100 provides a tool to identify inmate records 702 basedon alias names.

A diminutive record 710 has diminutive data and actual name data. Thediminutive record 710 is linked to the inmate record by the actual namedata of the diminutive record and the name data of the inmate record.The system 100 can process an inmate search request comprising searchname data for the inmate, determine that the search name data matchesthe diminutive data, return the inmate record, and populate the bookingrecord using the inmate record. The virtual jacket system 100 can usediminutive data to generate search results and locate relevant inmaterecord 702. The virtual jacket system 100 can use the diminutive record710 to match diminutive data to search data based on a similaritymeasure. The similarity measure can be generated based on string orcharacter similarities. The similarity measure can also be generatedbased on phonetic similarities.

The system 100 can generate phonetic diminutive data. The system 100 candetermine that the phonetic search name data matches the phoneticdiminutive data within the commonality rank, return the inmate record,and populate the booking record using the inmate record. This creates aflexible tool for system 100 to locate relevant inmate records andexpands search data to include diminutive names. The virtual jacketsystem 100 can use the diminutive record 710 to match diminutive data tosearch name data using a similarity measure meant that can be generatedbased on a phonetic similarity between the diminutive data and thesearch name data. As noted, the diminutive record 710 with the similardiminutive data can be used to identify the corresponding inmate record702 based on a similarity between actual name data of the diminutiverecord 710 and name data stored in the inmate record 702. The virtualjacket system 100 can identify the inmate record 702 which may nototherwise be identified based on a direct comparison between the storedname data in the inmate record 702 and the search name data.Accordingly, use of diminutive data by virtual jacket system 100provides a tool to identify inmate records 702 based on diminutivenames.

The virtual jacket system 100 aggregates data from multiple disparatefacility systems. The large data set from different sources may includemultiple references to the same inmate or individual as the formattingor naming convention may not be standardized across the different datasources. The virtual jacket system 100 uses phonetic encoding, aliasnames, and diminutive names to create a broader set of matching rulesand parameters. Virtual jacket system 100 can use both phoneticsimilarities and string or character similarities between search dataand store data to identify relevant inmate records 702. The similaritymeasurement or commonality rank defines a range of acceptable variancebetween search data and store data.

The virtual jacket system 100 receives search terms including searchname data. An example of search name data includes Lastname=Shizenuvskee, First name=Chuck. For this example, the virtualjacket system 100 can identify and return inmate record 702 storing namedata including Last name=Kryzanowski, First name=Charles. This is anexample only. The virtual jacket system 100 uses a set of rules todetermine inmate records along with phonetic encoders, alias data anddiminutive data to identify inmate records that would not be otherwiselocated using a basic search. The system 100 uses a set of rules toidentify a subset of one or more inmate records using the search namedata. The example rules can select inmate records using rules to joinsubsets of results from different searches including results from aphonetic data match, alias data match or diminutive data match. Thephonetic key record 708 has an encoder that virtual jacket system 100can use to transform search name data from search queries into phoneticsymbols and stored name data in inmate record 702 into phonetic symbols.The virtual jacket system 100 can match the phonetic symbols for thesearch name data into and the phonetic symbols for inmate using acommonality rank or similarity threshold. The system 100 can locate aninmate record 702 using these phonetic rules an encoding. An otherwiseliteral string, character or symbol comparison might not unable virtualjacket system 100 to locate the relevant inmate record 702. Instead, thevirtual jacket system 100 provides a broad and flexible search tool tomatch search data against stored data based on a set of characteristics.

The virtual jacket system 100 can use the offender phonetic key record706 to match the search name data (e.g. Shizenuvskee) and stored namedata (e.g. Kryzanowski) based on their phonetic similarity to generatesearch results. The virtual jacket system 100 can implement the phoneticcomparison in addition to string or character comparisons to generatesearch results. Accordingly, the virtual jacket system 100 can identifystored name data based on its phonetic similarity to search name datawhich may not otherwise be identified based on string or charactersimilarity. The virtual jacket system 100 can use the alias record 704to match the search name data (e.g. Chuck) and stored name data (e.g.Charles) based on the similarity of the strings, characters, or symbols.The virtual jacket system 100 can use the alias record 704 to comparealias data to the search data to identify a relevant inmate record 702.The virtual jacket system 100 can use the alias record 704 to match thesearch name data (e.g. Chuck) and stored name data (e.g. Charles) basedon the phonetic similarity. The virtual jacket system 100 can use thealias record 704 and the offender phonetic key record 706 to match thesearch name data to the store alias data based on its phoneticsimilarity. The virtual jacket system 100 can then use the globalidentifier of the alias record 704 to identify the relevant inmaterecord 702. Accordingly, the virtual jacket system 100 can match searchname data to stored name data using an alias to identify an inmaterecord 702 that might not otherwise be flagged if an alias was notconsidered.

FIG. 8 is a flowchart of a process for the virtual jacket system 100 andfacility system 104 according to some embodiments. The facility system104 includes a data onboard unit 830, jailtracker or on-premise database832, and a scheduled job unit 834. The virtual jacket system 100includes a virtual jacket web application programming interface (API)836 and a virtual jacket database 838. The process can be used tocontinuously synchronize the data stored by the virtual jacket system100 and the data in the different facility systems 104. The process usesa schedule or and a queue record to continuously monitor differentfacility systems 104 to trigger updates to the data stored by thevirtual jacket system 100.

At 802, as each new facility system 104 elects to participate in datasharing, virtual jacket system 100 executes a script against theon-premise database 832, creating a new interface queue record per thehistorical Booking record. A scheduler will pick up the queue record forprocessing over time. The virtual jacket system 100 on boards data fromthe facility system 104 and continuously monitors and updates its datafrom the facility system 104 based on the=queue and scheduling.

At 804, end-user system 840 performs an update anywhere in the virtualjacket system 100 and facility system 104, with the data API(jailtracker client 842) recording from which system feature of thevirtual jacket system 100 and facility system 104 the update originates.The virtual jacket system 100 can include a source identifier inrelation to data elements to identify the facility system 104 that theupdate originated from.

At 806, when the system feature is detected related to an externalinterface (via configuration), jailtracker client 842 creates a queuerecord in the on-premise facility system 104, noting which feature wasused and the appropriately identifying values unique to the new data.The virtual jacket system 100 can use this data to populate the sourceidentifier.

At 808, a scheduled task runs on the on-premise facility system 104operating system, however frequently the customer or external systemrequires. Scheduling in minutes allows near-real time updates ofexternal systems. Each job iteration retrieves all currently unprocessedqueue records based on a status marker. The virtual jacket system 100checks for updated data from the new facility system 104 at thescheduled time in order to continuously update the store data. Thevirtual jacket system 100 can transform the updated data from the newfacility system 1042 populate it stored records.

At 810, for each queue record, a job is initiated, containing customcode specific to interacting with the external interface.

At 812, as an interface job is started, the queue record is marked witha ‘Processing’ status, so not to be pulled by the scheduler again. Theappropriate data corresponding to the type of queue record is retrievedfrom the on-premise facility system 104 database, then handed to the jobschedule unit 834.

At 814, for Virtual Jacket web API 836 interface, the job schedule unit834 transforms the data into Entity-Attribute-Value (EAV) format,corresponding to the entity schema. The EAV data is then posted over asecured web service boundary for processing. The web service accepts EAVrepresented as XML3 or JSON4, for example, and contains a pluggabledeserialization layer in case of future transport format improvements.Accordingly, the virtual jacket system 100 can use predefined schemas totransform data from the different facility systems 104 into a commondata format or schema.

At 816, if the data is already in native Virtual Jacket format, notranslation is necessary. However, for third parties unable to conformto the native schema or data format, a pluggable translation layer isprovided so that custom code may be written to mutate external data intonative format before storage in the Virtual Jacket system 100 (database838) sparse matrix.

At 818, once the data is stored in the virtual Jacket system 100(database 838), unique entity identifiers are created in Virtual Jacketdatabase 838, and returned to the requestor (e.g. job schedule unit 834)for future synchronization ability. Accordingly, the entity identifierscan link data records stored by the virtual jacket system 100 andcorresponding data records stored by a remote facility system 104. Whenan update is detected at a data record stored by a remote facilitysystem 104 then the virtual jacket system 100 can use the entityidentifier to make a corresponding update to its data record linkedthereto.

At 820, the scheduled custom job for Virtual Jacket system 100 receivesthe external ID and associates the appropriate records within theon-premise database with the external Virtual Jacket identifiers forfuture synchronization reference.

At 822, the queue record is then closed with a ‘Success’ marker, furtherpreventing re-processing during the future scheduler iterations. Uponany errors and failures, they are logged and associated with the queuerecord, which is marked accordingly to expose it for re-processing onthe next scheduled iteration, which allows for outages and maintenancewindows at the Virtual Jacket data center facility.

FIGS. 9 to 16 provide example screenshots of interfaces, includingsearch interfaces and report, hold request interfaces. The reference JTrefers to JailTracker, a client application for the facility system 104.The client application provides an on premise data source for VirtualJacket data in some embodiments.

FIG. 9 shows a screen shot for Initiating Virtual Jacket (tool barbutton) from the JT main screen along with different search fields. Thescreenshot shows an interface for the virtual jacket system 100. Theinterface includes a form of form fields to receive and display datastored by the virtual jacket system 100 in different records. Forexample, the interface includes an offender form with multiple formfields including name data, identification data, classification data,facility data and incarceration status. The name data can include lastname, first name, alias, maiden name, diminutive name and so on. Theidentification data can include a global identifier, a booking number, aSocial Security or insurance number, foreign identification number,phone number, and other features. The classification data can include asecurity classification, gang affiliation, cells, age, gender, releasedate, and booked date, for example. The offender form includes formfields that can be populated through data entry or automatically usingstore data. For example, entering a global identifier can trigger anupdate to interface two populate the form fields with data stored in aninmate record 702 corresponding to the global identifier. The data canbe updated at the form which can in turn trigger updates to the storedata.

FIG. 10 shows a screen shot for a Virtual Jacket search laid over thetop of the same JT main screen (data pre-populates, pushed from mainsearch screen automatically into Virtual Jacket search fields). Thescreenshot shows an interface for the virtual jacket system 100 thatincludes a search form of form fields to receive search data to triggerthe return and display of results data. The search form can includedifferent search fields such as search name data, search identificationdata, search classification data, search facility data, searchincarceration status data, and so on. The search form of form fieldsreceives search data as a search query. The virtual jacket system 100processes the search data to generate result data for display as part ofthe search form or as a separate results interface or window. Theresults interface can enable actions to be implemented by virtual jacketsystem 100 such as booking an inmate, adding a hold, adding an alert,and requesting more information.

FIGS. 11 and 12 show screenshot of an interface with full and emptyVirtual Jacket search form, including a full and filled-in VirtualJacket search fields with results and details. The search form caninclude different fields such as name fields, identification numberfields, birthdate fields and so on. The search screen can includedifferent action triggers such as a new booking, a hold, book fromsearch results, and so on. The search form can indicate search resultssuch as a listing of inmates that match search data within a similaritymeasurement, for example. The listing of inmates includes multipleselectable inmate references that can be used to trigger additionalactions such as a booking or a hold, for example. The listing of inmatesis a set of selectable inmate references. The inmates in the listing canbe ranked based on similarity measurement, where more similar resultsare returned higher in the list than less similar results.

FIG. 13 shows a supplemental detail screen (named more info, currently).The supplemental information screen can provide additional informationregarding an inmate for example. The additional information can includealert information, incident information release details and so on. Theadditional information includes a listing of data elements. Each dataelement is selectable for modification. FIGS. 14 and 15 show screenshots of the process for creating and viewing the remote holds, bothfrom the perspective of a JT user seeing a hold placed by a remoteagency having used Virtual Jacket system 100. For example, thescreenshot shows an interface with a hold form for creating a hold. Thehold form includes multiple fields for creating a hold. Example fieldsinclude contact name, contact phone number, time period for the hold,reason for the hold, and so on. The hold form can integrate with theresults form. For example an inmate search can return an inmate record.The inmate record can be selectable to create a hold for the inmateidentified in the record. The virtual jacket system 100 can display thehold form that can be auto populated with data from the stored inmaterecord along with other store data. The virtual jacket system 100 thencreates a hold record linked corresponding inmate record by a globalidentifier. A subsequent search for the inmate can also trigger a returnof the relevant hold information.

FIG. 16 shows a screenshot from another remote agency (facility system104) seeing another remote agency's hold from within Virtual Jacketsystem 100. Accordingly, virtual jacket system 100 enables remotefacility systems 104 to connect and share data.

FIG. 17 is a diagram of data structures 1700 and links for datasynchronization according to some embodiments. An alert record 1702 hasdifferent fields and is create alerts or notifications to alert facilitysystem 104 and virtual jacket system 100 for data updates,inconsistency, verifications, expiration, and so on. The alert record1702 fields include foreign and primary key fields such as alertidentifier, agency (facility system 104) identifier, and JacketNumberidentifier (an example global identifier). Other fields include active,expiration date, category, details, keep apart name, and so on. Acontact record 104 has different fields including foreign and primarykey fields such as contact identifier, agency identifier, andJacketNumber identifier. An alias record 1706 has different fields fordifferent alias instances including foreign and primary key fields suchas alias identifier, agency (facility system 104) identifier,JacketNumber. The alias record 1706 has a name field. A hold record 1708has different fields including foreign and primary key fields such ashold identifier, agency identifier, and JacketNumber. The hold record1708 has other fields including received date, expiration date,HoldForAgency identifier, Reason, CriminalCode, and so on.

An agency (facility system 104) record 1710 has different fieldsincluding foreign and primary key fields such as an agency identifier.The agency (facility system 104) record 1710 has other fields includingagency name, contact name for holds and contact number for holds.

An offender record 1712 has different fields including foreign andprimary key fields such as JacketNumber identifier and agencyidentifier. The offender record 1712 has other fields including socialsecurity number, first name, middle name, last name, maiden name,gender, birth date, birth place, deceased date, race, ethnicity,nationality, hair color, eye color, height, weight, and so on.

A booking record 1714 has different fields including foreign and primarykey fields such as JacketNumber identifier and agency identifier. Thebooking record 1714 has other fields including booking number, initialbook time and date, and so on.

A release record 1716 has different fields including foreign and primarykey fields such as agency identifier, image identifier and a bookingnumber. The release record 1716 has other fields including release code,release date and time, incarceration status, scheduled rebook date,scheduled release date and so on.

A charge record 1718 has different fields including foreign and primarykey fields such as agency identifier, a charge identifier, and a bookingnumber. The charge record 1718 has other fields including country ofcharge, offense date, statute, crime type, crime class, charge, NCICcode, arresting agency, arresting officer, arrest date, state of charge,offense type, warrant number, warrant agency, and so on.

An image record 1720 has different fields including foreign and primarykey fields such as agency identifier, an image identifier, and a bookingnumber. The image record 1720 has other fields including type,description, eye characteristics, face shape, body location, image filename, and so on.

These are example records and fields for the data synchronization.

The inmate record 1712 includes a global identifier that connects orlinks to other records. For example, the inmate record 1712 is linked tothe alias record 1706 by the global identifier. As another example, theinmate record 1712 is linked to the alert record 1702 by the globalidentifier. The inmate record 1712 can also be linked to a contactrecord 1704 by the global identifier and a hold record 1708 by theglobal identifier. Accordingly, the global identifier provides a way tolink different records and fields or entry values of the records.

In some embodiments, the inmate record 1712 can be linked to a bookingrecord 1714 by the global identifier. The booking record 1714 can alsoinclude a booking identifier. A charge record 1718 can be linked to thebooking record 1714 by the booking identifier. An image record 1720 canbe linked to the booking record 1714 by the booking identifier, and theimage record 1720 can include images and descriptions of inmates. Arelease record 1716 can be linked to the booking record 1714 by thebooking identifier.

FIG. 18 shows an example computing device that may be used to implementaspects of virtual jacket system 100 or facility system 104. The virtualjacket system 100 includes at least one processor 1802, memory 1804, atleast one I/O interface 1806, and at least one network interface 1808.

Each processor 1802 may be, for example, any type of general-purposemicroprocessor or microcontroller, a digital signal processing (DSP)processor, an integrated circuit, a field programmable gate array(FPGA), a reconfigurable processor, a programmable read-only memory(PROM), or any combination thereof.

Memory 1804 may include a suitable combination of any type of computermemory that is located either internally or externally such as, forexample, random-access memory (RAM), read-only memory (ROM), compactdisc read-only memory (CDROM), electro-optical memory, magneto-opticalmemory, erasable programmable read-only memory (EPROM), andelectrically-erasable programmable read-only memory (EEPROM),Ferroelectric RAM (FRAM) or the like.

Each I/O interface 1806 enables computing device to interconnect withone or more input devices, such as a keyboard, mouse, camera, touchscreen and a microphone, or with one or more output devices such as adisplay screen and a speaker.

Each network interface 1808 enables computing device to communicate withother components, to exchange data with other components, to access andconnect to network resources, to serve applications, and perform othercomputing applications by connecting to a network (or multiple networks)capable of carrying data including the Internet, Ethernet, plain oldtelephone service (POTS) line, public switch telephone network (PSTN),integrated services digital network (ISDN), digital subscriber line(DSL), coaxial cable, fiber optics, satellite, mobile, wireless (e.g.Wi-Fi, WiMAX), SS7 signaling network, fixed line, local area network,wide area network, and others, including any combination of these.

Computing device is operable to register and authenticate users (using alogin, unique identifier, and password for example) prior to providingaccess to applications, a local network, network resources, othernetworks and network security devices. Computing device may serve oneuser or multiple users.

The embodiments of the devices, systems and methods described herein maybe implemented in a combination of both hardware and software. Theseembodiments may be implemented on programmable computers, each computerincluding at least one processor, a data storage system (includingvolatile memory or non-volatile memory or other data storage elements ora combination thereof), and at least one communication interface.

Program code is applied to input data to perform the functions describedherein and to generate output information. The output information isapplied to one or more output devices. In some embodiments, thecommunication interface may be a network communication interface. Inembodiments in which elements may be combined, the communicationinterface may be a software communication interface, such as those forinter-process communication. In still other embodiments, there may be acombination of communication interfaces implemented as hardware,software, and combination thereof.

Throughout the foregoing discussion, numerous references will be maderegarding servers, services, interfaces, portals, platforms, or othersystems formed from computing devices. It should be appreciated that theuse of such terms is deemed to represent one or more computing deviceshaving at least one processor configured to execute softwareinstructions stored on a computer readable tangible, non-transitorymedium. For example, a server can include one or more computersoperating as a web server, database server, or other type of computerserver in a manner to fulfill described roles, responsibilities, orfunctions.

The following discussion provides many example embodiments. Althougheach embodiment represents a single combination of inventive elements,other examples may include all possible combinations of the disclosedelements. Thus if one embodiment comprises elements A, B, and C, and asecond embodiment comprises elements B and D, other remainingcombinations of A, B, C, or D, may also be used.

The term “connected” or “coupled to” may include both direct coupling(in which two elements that are coupled to each other contact eachother) and indirect coupling (in which at least one additional elementis located between the two elements).

The technical solution of embodiments may be in the form of a softwareproduct. The software product may be stored in a non-volatile ornon-transitory storage medium, which can be a compact disk read-onlymemory (CD-ROM), a USB flash disk, or a removable hard disk. Thesoftware product includes a number of instructions that enable acomputer device (personal computer, server, or network device) toexecute the methods provided by the embodiments.

The embodiments described herein are implemented by physical computerhardware, including computing devices, servers, receivers, transmitters,processors, memory, displays, and networks. The embodiments describedherein provide useful physical machines and particularly configuredcomputer hardware arrangements. The embodiments described herein aredirected to electronic machines and methods implemented by electronicmachines adapted for processing and transforming electromagnetic signalswhich represent various types of information. The embodiments describedherein pervasively and integrally relate to machines, and their uses;and the embodiments described herein have no meaning or practicalapplicability outside their use with computer hardware, machines, andvarious hardware components. Substituting the physical hardwareparticularly configured to implement various acts for non-physicalhardware, using mental steps for example, may substantially affect theway the embodiments work. Such computer hardware limitations are clearlyessential elements of the embodiments described herein, and they cannotbe omitted or substituted for mental means without having a materialeffect on the operation and structure of the embodiments describedherein. The computer hardware is essential to implement the variousembodiments described herein and is not merely used to perform stepsexpeditiously and in an efficient manner.

Although the embodiments have been described in detail, it should beunderstood that various changes, substitutions and alterations can bemade herein without departing from the scope as defined by the appendedclaims.

Moreover, the scope of the present application is not intended to belimited to the particular embodiments of the process, machine,manufacture, composition of matter, means, methods and steps describedin the specification. As one of ordinary skill in the art will readilyappreciate from the disclosure, processes, machines, manufacture,compositions of matter, means, methods, or steps, presently existing orlater to be developed, that perform substantially the same function orachieve substantially the same result as the corresponding embodimentsdescribed herein may be utilized. Accordingly, the appended claims areintended to include within their scope such processes, machines,manufacture, compositions of matter, means, methods, or steps.

As can be understood, the examples described above and illustrated areintended to be exemplary only.

1. An inmate facility management system comprising: a shared storagedevice to store a plurality of inmate records and a plurality offacility records from multiple disparate facility systems; an interfaceto receive a search request for an open bed in a facility system for aninmate; a processor configured to: translate data from the multipledisparate facility systems to the plurality of inmate records and theplurality of facility records; determine in real time a set of open bedsfor an aggregated jail capacity using the plurality of inmate recordsand the plurality of facility records from the multiple disparatefacility systems; update the interface to indicate the set of open bedsfor the aggregated jail capacity; receive a booking request to book theopen bed from the set of open beds; update an inmate record of theplurality of inmate records corresponding to the inmate and a facilityrecord of the plurality of facility records corresponding to thefacility system; populate a booking record for the open bed using theinmate record and the facility record; and update the interface todisplay the booking request, the inmate record and the facility record.2. The inmate facility management system of claim 1 wherein theprocessor is configured to process the booking request by executing alocal and extended search using a link between a local inmate record anda shared inmate record, populate the booking record using the results ofthe local and extended search, and update the local inmate record andthe shared inmate record to indicate the booking record.
 3. The inmatefacility management system of claim 1 wherein the processor isconfigured to receive a warrant request, execute a local and extendedsearch using the warrant request and a link between a local inmaterecord and a shared inmate record, generate a hold request based on theresults of the local and extended search, and update the local inmaterecord and the shared inmate record to indicate the hold request.
 4. Theinmate facility management system of claim 1 wherein the processor isconfigured to receive a release request, execute a local and extendedsearch using the release request and a link between a local inmaterecord and a shared inmate record, populate a release record using theresults of the local and extended search, and update the local inmaterecord and the shared inmate record to indicate the release request. 5.The inmate facility management system of claim 1 wherein the inmaterecord has a plurality of fields comprising a global identifier and namedata, the shared storage device storing an inmate phonetic key recordlinked to the inmate record by the global identifier, a phonetic keyrecord linked to the inmate phonetic key by a phonetic key identifier,the inmate phonetic key record comprising a commonality rank, thephonetic key record comprising encoding for transforming the name datainto phonetic name data, the processor configured to process an inmatesearch request comprising search name data for the inmate, generatephonetic search name data, determine that the phonetic search name datamatches the phonetic name data within the commonality rank, return theinmate record, and populate the booking record using the inmate record.6. The inmate facility management system of claim 5 wherein the sharedstorage device stores an alias record having alias data, the aliasrecord linked to the inmate record by the global identifier, theprocessor configured to generate phonetic alias data, determine that thephonetic search name data matches the phonetic alias data within thecommonality rank, return the inmate record, and populate the bookingrecord using the inmate record.
 7. The inmate facility management systemof claim 5 wherein the shared storage device stores a diminutive recordhaving diminutive data and actual name data, the actual name data of thediminutive record linked to the name data of the inmate record, theprocessor configured to generate phonetic diminutive data, determinethat the phonetic search name data matches the phonetic diminutive datawithin the commonality rank, return the inmate record, and populate thebooking record using the inmate record.
 8. The inmate facilitymanagement system of claim 1 wherein the inmate record has a pluralityof fields comprising a global identifier and name data, the sharedstorage device storing an alias record linked to the inmate record bythe global identifier, the alias record having alias data, the processorconfigured to process an inmate search request comprising search namedata for the inmate, determine that the search name data matches thealias data, return the inmate record, and populate the booking recordusing the inmate record.
 9. The inmate facility management system ofclaim 1 wherein the inmate record has a plurality of fields comprising aglobal identifier and name data, the shared storage device storing adiminutive record having diminutive data and actual name data, thediminutive record linked to the inmate record by the actual name data ofthe diminutive record and the name data of the inmate record, theprocessor configured to process an inmate search request comprisingsearch name data for the inmate, determine that the search name datamatches the diminutive data, return the inmate record, and populate thebooking record using the inmate record.
 10. The inmate facilitymanagement system of claim 1 wherein the processor is configured tosynchronize the data storage device storing the plurality of inmaterecords and the plurality of facility records with updated data from themultiple disparate facility systems.
 11. The inmate facility managementsystem of claim 10 wherein the processor is configured to synchronizethe data storage device by receiving an election to participate in datasharing from a first facility system, storing a new facility record forthe first facility system, loading additional data from the firstfacility system, translating the additional data into a common schema toupdate the plurality of inmate records, and creating a new queue recordfor a scheduler to continuously check the first facility system forfurther data over a time period.
 12. The inmate facility managementsystem of claim 10 wherein the processor is configured to synchronizethe data storage device using an application programming interfacebetween a client interface at a first facility system and a cloudinterface at the data storage device.
 13. The inmate facility managementsystem of claim 10 wherein the processor is configured to synchronizethe data storage device by assigning unique global identifiers that areused for records of the disparate facility systems and the data storagedevice.
 14. A process for an inmate facility management systemcomprising: storing, on a shared storage device, a plurality of inmaterecords and a plurality of facility records from multiple disparatefacility systems; receiving, at a processor, a search request for anopen bed in a facility system for an inmate; translating data from themultiple disparate facility systems to the plurality of inmate recordsand the plurality of facility records; determining, at the processor inreal time, a set of open beds for an aggregated jail capacity using theplurality of inmate records and the plurality of facility records fromthe multiple disparate facility systems; updating an interface toindicate the set of open beds for the aggregated jail capacity;receiving a booking request to book the open bed from the set of openbeds; updating an inmate record of the plurality of inmate recordscorresponding to the inmate and a facility record of the plurality offacility records corresponding to the facility system; populating abooking record for the open bed using the inmate record and the facilityrecord; and updating the interface to display the booking request, theinmate record and the facility record.
 15. The process of claim 14further comprising processing the booking request by executing a localand extended search using a link between a local inmate record and ashared inmate record, populating the booking record using the results ofthe local and extended search, and updating the local inmate record andthe shared inmate record to indicate the booking record.
 16. The processof claim 14 further comprising receiving a warrant request, executing alocal and extended search using the warrant request and a link between alocal inmate record and a shared inmate record, generating a holdrequest based on the results of the local and extended search, andupdating the local inmate record and the shared inmate record toindicate the hold request.
 17. The process of claim 14 furthercomprising receiving a release request, executing a local and extendedsearch using the release request and a link between a local inmaterecord and a shared inmate record, populating a release record using theresults of the local and extended search, and updating the local inmaterecord and the shared inmate record to indicate the release request. 18.The process of claim 14 further comprising generating the inmate recordwith a global identifier and name data, storing an inmate phonetic keyrecord linked to the inmate record by the global identifier, a phonetickey record linked to the inmate phonetic key by a phonetic keyidentifier, the inmate phonetic key record comprising a commonalityrank, the phonetic key record comprising encoding for transforming thename data into phonetic name data, processing an inmate search requestcomprising search name data for the inmate, generating phonetic searchname data, determining that the phonetic search name data matches thephonetic name data within the commonality rank, returning the inmaterecord, and populating the booking record using the inmate record. 19.The process of claim 14 further comprising storing an alias recordhaving alias data, the alias record linked to the inmate record by theglobal identifier, generating phonetic alias data, determine that thephonetic search name data matches the phonetic alias data within thecommonality rank, returning the inmate record, and populating thebooking record using the inmate record.
 20. The process of claim 14further comprising storing a diminutive record having diminutive dataand actual name data, the actual name data of the diminutive recordlinked to the name data of the inmate record, generating phoneticdiminutive data, determining that the phonetic search name data matchesthe phonetic diminutive data within the commonality rank, returning theinmate record, and populating the booking record using the inmaterecord.
 21. The process of claim 14 further comprising generating theinmate record with a global identifier and name data, the shared storagedevice storing an alias record linked to the inmate record by the globalidentifier, the alias record having alias data, the processor configuredto process an inmate search request comprising search name data for theinmate, determine that the search name data matches the alias data,return the inmate record, and populate the booking record using theinmate record.
 22. The process of claim 14 further comprising generatingthe inmate record with a global identifier and name data, storing adiminutive record having diminutive data and actual name data, thediminutive record linked to the inmate record by the actual name data ofthe diminutive record and the name data of the inmate record, processingan inmate search request comprising search name data for the inmate,determining that the search name data matches the diminutive data,return the inmate record, and populating the booking record using theinmate record.
 23. (canceled)
 24. (canceled)
 25. (canceled) 26.(canceled)
 27. An inmate facility management device comprising: aninterface to access a shared storage device storing a plurality ofinmate records and a plurality of facility records from multipledisparate facility systems, and receive a search request for an open bedin a facility system for an inmate; a processor configured to: translatedata from the multiple disparate facility systems to the plurality ofinmate records and the plurality of facility records; determine in realtime a set of open beds for an aggregated jail capacity using theplurality of inmate records and the plurality of facility records fromthe multiple disparate facility systems; update the interface toindicate the set of open beds for the aggregated jail capacity; receivea booking request to book the open bed from the set of open beds; updatean inmate record of the plurality of inmate records corresponding to theinmate and a facility record of the plurality of facility recordscorresponding to the facility system; populate a booking record for theopen bed using the inmate record and the facility record; and update theinterface to display the booking request, the inmate record and thefacility record. 28.-53. (canceled)